When cleaning ALL changelog rows, indexes get confused after a MySQL restart. The changelog version ids can start over at 1, and mview_state will be ahead of it.

This causes incremental indexing to simply not execute.

Description

To prevent this, we always keep the highest version id row, which makes MySQL handle auto_increment as expected, even after a restart.

Fixed Issues (if relevant)

See Cloud issue 14833.

Manual testing scenarios

1. Verify that the indexes are all set to "schedule" mode: php bin/magento indexer:set-mode schedule.
2. Cause many (> 1000) updates to be written to a changelog (e.g. by modifying 1000 products.)
3. Validate that the changes have indexed after a short while (this requires the cron to be running.)
4. Wait until the next hour. Changelog cleaning happens once an hour at 0 minutes.
5. Check the changelog to see what entries remain in the table.
6. Restart the MySQL service.
7. Cause at least one, possible several updates to be written to a changelog (e.g. by modifying products.)
8. Validate that the changes have indexed after a short while.

Actual results (before this PR):
At step 5, zero entries remain in the _cl table.
At step 8, the changes never index.

Expected results:
At step 5, one entry remains in the _cl table.
At step 8, the changes successfully update.

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds on Travis CI are green)